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PREFACE 


This  report  was  prepared  by  The  BOM  Corporation,  Technology 
Applications  Center,  P.  0.  Box  9274,  Albuquerque,  New  Mexico  87119 
under  the  Defense  Nuclear  Agency  contract  DNA001-80-C-0083.  Captain 
S.  W.  Achromowicz  is  the  Contracting  Officer's  Representative. 

This  report  presents  the  status  of  the  Engineering  Development  phase 
for  the  TNF  $3  Instrumentation  Development  effort.  This  instrumentation 
is  needed  to  satisfy  the  test  analysis  and  evaluation  requirements  on 
force-on-force,  free-play  testing  of  the  TNF  $3  using  real-time  casualty 
assessment.  The  instrumentation  design  philosophy  centered  around  a 
system  that  is  to  be  modular,  flexible,  and  expandable.  The  instru¬ 
mentation  will  be  portable,  will  not  require  extensive  field  support,  and 
in  some  cases  will  be  secure  from  outside  monitoring.  Existing  off-the- 
shelf  technology  is  being  used  to  minimize  development  risk. 

The  instrumentation  system  consists  of  three  basic  elements.  The 
master  station  performs  the  operations  and  maintenance,  calibration,  test 
control,  and  data  quick-look  tasks.  The  RF  communications  system  allows 
for  two-way  communications  from  the  master  station  via  repeaters  to  the 
players,  and  will  evolve  into  an  accurate  transponder  position  location 
subsystem.  The  player  instrumentation  contains  a  microcomputer  and  will 
be  capable  of  totally  decentralized  operations.  It  will  perform  the 
functions  of  position  location,  weapon  simulation  (weapon  and  target 
sensors),  player  cueing,  data  logging,  RF  communications  with  the  master 
station,  and  the  computation  of  real-time  casualty  assessments. 
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SUMMARY  OF  ACCOMPLISHMENTS 
FOR  THE  PERIOD 

15  JANUARY  1981  THROUGH  30  JUNE  1981 

1  INTRODUCTION. 

This  report  summarizes  the  tasks  accomplished  on  the  TNFS3 
instrumentation  development  for  the  period  of  15  January,  1981  through  30 
June,  1981.  It  is  not  intended  to  be  a  stand-alone  document,  but  supple¬ 
ments  the  Theater  Nuclear  Force  Survivability.  Security  and  Safety  In¬ 
strumentation  -  Final  Report  "Engineering  Development  Phase  -  Fiscal  Year 
1980"  dated  31  December,  1980.  This  effort  was  reduced  in  scope  due  to 
limited  funding  and  the  effort  was  limited  to  system  base  testing,  devel¬ 
opment  of  an  expanded  Player  Initializer  to  replace  the  master  station, 
implementation  of  the  executive  control  system  operating  system  software 
on  the  Phase  II  microcomputer,  and  the  development  of  a  simplified 
position-location  algorithm,  and  real-time  casualty  assessment  capability. 
All  of  the  above  objectives  were  met  and  a  great  deal  of  effort  was 
expended  to  correct  deficient  government-furnished  equipments,  namely  the 
weapons  effects  subsystems. 

2  SYSTEM  LEVEL  TESTING. 

The  system-level  tests  were  initially  planned  to  take  place  at 
the  DNA  ARES  facility  but  were  performed  in  the  open  area  behind  the  BDM 
R&D  Laboratory  for  reasons  of  convenience  and  cost  effectiveness.  Testing 
was  conducted  on  the  following  subsystems. 

(a)  RF  transceiver  characterization. 

(b)  Player  to  transponder  ranging  evaluation. 

(c)  RF  communications  evaluation. 

(d)  Weapons  effects  subsystem  evaluation. 


2.1  RF  Transceiver  Characterization. 

The  RF  transceiver  tests  were  conducted  to  verify  the  operation 
of  the  government-furnished  RF  units  produced  by  VEGA  Precision  Labora¬ 
tories,  Vienna,  Virginia.  The  tests  evaluated  the  unit-to-unit  variance 
of  RF  transceivers  over  a  known  range.  Signal  amplitude  measurements 
were  taken  for  three  antenna  orientations  (vertical,  horizontal,  and 
axial)  for  the  Player  Pack  systems  which  use  a  vertical  antenna  to  the 
omni-directional  antenna  used  at  the  repeater/transponder  towers.  These 
data  allowed  the  generation  of  range  correction  tables  for  use  in  the 
Player  Packs.  The  plot  of  the  range-versus-ampl itude  corrections  are 
shown  in  Figure  1. 

The  RF  units  were  also  tested  for  sensitivity  and  false  alarm 
rates.  The  results  of  these  tests  indicated  that  a  minor  modification 
was  needed  to  the  receive  inhibit  during  the  transponder  position-loca¬ 
tion  mode.  This  was  accomplished  by  using  existing  signals  within  the  RF 
unit's  digital  board.  The  sensitivity  was  also  evaluated  and  all  of  the 
units  have  been  set  to  approximately  -65  dBm.  This  setting  proved  to  be 
satisfactory  to  optimize  the  maximum  range  and  had  an  extremely  low  false 
alarm  rate. 

2.2  Player  to^Transponder  Ranging  Evaluation. 

These  tests  were  performed  in  early  June.  A  four-transponder 
network.  Player  Initializer,  and  two  players  were  tested  individually. 
The  transponders  were  placed  in  a  40-by-70-meter  grid  and  the  Player  Pack 
was  positioned  relative  to  the  grid.  The  Player  Initializer  controlled 
the  test  and  performed  the  following  functions: 

(a)  Request  player  event  data  -  every  2  seconds. 

(b)  Request  player  group  to  "get  ready"  to  do  position  loca¬ 
tion  -  every  10  seconds. 

(c)  Request  player  group  to  "do"  position  location  -  every  10 
seconds. 


RANGE  COUNT 
CORRECTION  FACTOR 
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(d)  Display  player  operational  status  on  cathode  ray  tube 
(CRT)  #1  -  every  5  seconds. 

(e)  Display  player  status  on  CRT  #2  or  print  on  Silent  700  - 
when  events  are  available. 

Preliminary  results  showed  that  successive  ranging  measurements 
from  a  stationary  Player  Pack  to  a  transponder  were  within  +3  meters  and 
most  often  +2  meters,  and  that  the  Player  Pack  is  capable  of  accurate 
ranging  through  a  40-foot,  performed  (with  stressed  rebar)  concrete 
building.  This  test  setup  will  be  used  to  evaluate  the  actual  performance 
of  the  transponder  position-location  subsystem  and  the  position-location 
algorithm  during  the  proposed  follow-on  effort.  The  Player  Pack  communi¬ 
cated  directly  with  the  Player  Initializer  which  utilized  an  identical 
tower  arrangement. 

2.3  RF  Communications  Evaluation. 

The  RF  communications  evaluation  consisted  of  sending  and 

receiving  messages  to  and  from  a  Player  Pack  and  Player  Initializer  under 
various  conditions.  The  communications  protocol  was  as  follows: 

(a)  The  Player  Initializer  sends  a  "request  event  message"  to 

a  specific  Player  Pack  (each  Player  Pack  is  assigned  a 

unique  ID  number). 

(b)  The  Player  Pack  decodes  the  request  and,  if  it  was  for 

that  Player  Pack,  responds  with  either  a  "no  event"  or  a 
"position-location  event"  if  that  has  occurred. 

(c)  If  the  Player  Initializer  does  not  receive  a  return  mes¬ 
sage,  it  sets  a  "no  RF  communications"  flag  in  that 
player's  status  display  and  attempts  to  call  up  to  three 
more  times.  If  a  message  is  received  the  Player  Initial¬ 
izer  removes  the  flag  and  sends  a  "message  received"  to 
the  specific  Player  Pack.  The  Player  Pack  then  removes 
the  message  from  his  transmit  buffer  and  stores  it  in 
memory. 
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This  testing  was  an  excellent  exercise  of  both  the  Player 
Initializer  and  the  Player  Packs  as  it  demonstrated  the  possibility  of 
missing  RF  messages  on  the  first  or  second  try  due  to  external  RF 
emissions,  improper  sensitivity  setting,  and  antenna  positioning,  without 
actually  losing  any  data.  Additional  testing  is  planned  to  determine 
maximum  range  and  range  through  trees  and  foliage  during  the  follow-on 
effort. 

2.4  Weapons  Effects  Subsystems. 

Testing  and  checkout  of  the  6FE  weapons  effects  subsystems 
consumed  a  great  deal  of  the  total  effort  because  of  unreliable  cabling 
and  electronics  in  all  of  the  elements  except  the  rifle  laser.  The 
following  subparagraphs  describe  the  activities  performed  for  each  element 
of  the  weapons  effects  subsystem. 

2.4.1  Pistol  Laser.  Two  357  magnum  handgun  lasers  were  delivered  and 
accepted.  One  unit  was  inoperable  and  was  immediately  returned.  The 
second  was  evaluated.  It  operated  on  a  intermittant  basis  and  would 
often  shoot  multiple  rounds  on  a  single  trigger  pull.  The  unit  that  was 
returned  to  the  vendor  was  not  repairable  and  it  was  again  returned  to 
BOM.  BOM  undertook  the  task  of  determining  what  could  be  done  with  the 
handgun  laser  system  and  concluded  that  a  redesign  of  the  electronics  and 
the  packaging  was  required.  This  task  has  been  scoped  and  will  be  a 
follow-on  effort  with  the  goals  of  cost  reduction,  modular  design,  and 
high  reliability. 

2.4.2  Rifle  Laser.  The  M-16  rifle  laser  was  a  modification  of  the 
MAGLAD  training  laser  and  was  not  designed  specifically  for  TACTICS.  The 
laser  contains  many  discrete  components,  is  expensive,  and  is  considered 
too  large.  The  basic  circuitry  has  been  reviewed  and  a  redesign  using 
telescope  optics  has  been  scoped.  The  goals  of  the  redesign  are  to 
contain  identical  modules  as  the  357  handgun  and  to  remove  as  much  of  the 
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electronics  as  possible  from  the  laser  and  place  them  on  the  Player  Pack 
interface  printed  circuit  board.  Many  of  the  difficulties  encountered 
while  testing  the  rifle  lasers  concerned  the  lack  of  appropriate  test 
equipment  to  determine  beam  divergence  and  laser  intensity.  An  optical 
bench  has  been  identified  and  the  above  measurements  will  be  easily 
performed  in  the  follow-on  effort. 

The  model  M-16  assault  rifles  were  modified  to  use  the  trigger 
pull  to  activate  a  reed  switch  as  a  fire  event  rather  than  the  muzzle 
flash.  Four  additional  M-16  assault  rifles  were  backordered  and  the 
CAR-15  assault  rifle  was  substituted.  They  have  been  modified  and  are 
shown  in  Figure  2. 

2.4.3  Weapons  Effects  Communications  Interface  Unit.  The  circuitry 
of  the  6FE  WE  CIUs  required  major  modification.  A  buffer  integrated 
circuit  was  added  to  correct  a  problem  with  the  multiple  body  sensor 
latch,  eight  of  the  data  lines  had  to  be  reversed,  and  several  diodes 
were  added  to  the  units.  The  function  of  the  WE  CIU  was  evaluated  and  it 
was  recommended  that  a  new  unit  be  designed  in  conjunction  with  the  laser 
systems.  This  design  will  optimize  and  centralize  the  electronics  on  the 
CIU  card  and  remove  many  of  the  functions  now  being  done  on  the  weapon  or 
laser.  It  is  estimated  that  the  redesign  will  reduce  the  cost  of  produc¬ 
tion  WE  CIUs  by  50  percent  or  more. 

2.4.4  Weapons  Effects  Harness  and  Sensors.  After  several  months  of 
use,  a  number  of  design  deficiencies  have  been  identified  concerning  the 
weapons  effects  harness,  cloth  material,  and  sensors.  The  cable  presently 
utilized  is  difficult  to  work  with  and  difficult  to  repair.  The  routing 
of  the  cables  must  be  human  engineered  and  a  positive  locking  connector 
is  required.  The  vest  area  sensors  should  be  slightly  enlarged  to  cover 
the  side  of  rib  cage  and  a  more  realistic  material,  such  as  standard 
camouflage  material,  should  be  used  if  possible.  Earlier  studies  showed 
that  the  dark  green  and  black  coloring  of  the  standard  issue  camouflage 
material  did  not  allow  sufficient  energy  for  the  fiber  optic  area  sensor 


to  detect  the  laser  message.  Since  that  time,  however,  advances  have 
been  made  in  photo  cell  sensors  and  it  is  estimated  that  a  10  to  20 
decibel  gain  in  the  sensor  system  can  be  achieved.  This  evaluation  and 
design  of  ruggedized,  high-gain  sensor  has  been  scoped  and  will  be 
addressed  in  the  follow-on  effort. 

3  PLAYER  INITIALIZER  DEVELOPMENT. 

The  Player  Initializer  was  initially  conceived  as  a  support 
element  and  was  to  be  used  to  assign  identification  numbers  to  the  Player 
Packs  and  perform  an  in-the-field  checkout  of  all  of  the  Player  Pack 
elements.  Because  of  limited  funding,  subsets  of  the  command,  control, 
communications,  display,  and  recording  functions  planned  for  the  master 
station  were  programmed  into  the  Player  Initializer.  The  present  Player 
Initializer  is  not  intended  to  replace  the  master  station,  but  to  be  a 
small-scale  unit  that  can  adequately  handle  up  to  20  or  25  players  in 
real  time.  The  elements  of  a  full-up  Player  Initializer  are  shown  in 
Figure  3. 

The  Player  Initializer  was  constructed  using  two  of  the  stan¬ 
dard  TACTICS  card  cages  and  interconnecting  them  to  obtain  the  additional 
peripheral  slots  necessary  for  interfacing  to  the  CRTs  and  printer. 

The  Phase  II  microcomputer  was  programmed  using  two  EPROM  cards 
to  act  as  the  test  controller,  display  driver,  and  data  recorder.  A 
high-capacity  gell  cell  powers  the  TACTICS  microcomputer  and  the  associ¬ 
ated  peripherals,  whereas  the  CRTs  and  APPLE  display  unit  use  commercial 
60  Hz  115  volt  ac. 

3.1  Player  Initializer  Alphanumeric  Display  Subsystem. 

The  Player  Initializer  was  designed  to  drive  two  types  of 
alphanumeric  displays.  The  first  is  two  CRTs  which  display  the  status  of 
the  red  and  blue  teams  and  are  updated  every  10  seconds.  Only  the  data 
that  change  are  updated  and  the  CRT  remains  almost  flicker  free.  The 
format  for  the  event  display  is  shown  in  Figure  4  and  the  format  for  the 
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status  display  is  shown  in  Figure  5.  The  second  alphanumeric  display 
channel  is  a  hard  copy  unit.  As  shown  in  Figure  3,  a  Texas  Instruments 
Tuitcase  Silent  700  terminal  can  be  used.  This  unit  writes  30  characters 
per  second  and  is  used  to  list  key  events  only.  The  final  alphanumeric 
input/output  device  is  the  Key  Entry  Display  Unit  (KENDU).  It  was 
designed  to  be  used  with  the  basic  Player  Initializer  when  no  other 
display  device  was  available  or  needed  (such  as  during  a  small  test  or 
pretest  scenario  evaluation.)  The  KENDU  can  also  be  interfaced  to  a 
standard  Player  Pack  for  use  by  an  umpire  to  enter  key  events  and  obser¬ 
vations.  The  operation  of  the  Player  Initializer  can  originate  from  any 
one  of  the  CRTs,  the  Silent  700,  or  the  KENDU. 

3.2  Player  Initializer  Color  Display  System. 

The  color  display  system  consists  of  an  APPLE  II  microcomputer 
with  a  color  monitor,  a  graphics  tablet,  and  two  floppy  disks.  The 
system,  as  shown  in  Figure  6,  can  display  the  x  and  y  position  of  the  red 
and  blue  forces  and  the  graphics  tablet  is  used  to  draw  the  key  features 
of  the  test  area.  The  present  system  can  update  up  to  3  players  a  second 
and  could  handle  up  to  10  without  a  great  deal  of  flicker.  A  "score- 
board"  of  the  red  and  blue  team  wounded  and  killed  appears  at  the  bottom 
of  the  display.  Players  are  identified  by  numbers.  A  red  or  blue  bar 
above  the  number  designates  the  tean  and  a  red  or  yellow  bar  below  indi¬ 
cates  wounded  or  killed. 

3.3  Player  Initializer  Tape  Recorder  Subsystem. 

The  Player  Initializer  tape  recorder  system  will  record  the 
status  records  as  they  are  collected,  allowing  the  test  scenario  to  be 
replayed  for  analysis  and  for  immediate  feedback  during  the  after-action 
review.  This  unit,  the  MFE  Model  2508,  shown  in  Figure  7,  can  record  up 
to  128K  bytes  of  data  on  a  single  cassette  tape.  Its  control  card  was 
wite  wrapped  and  the  unit  was  functionally  tested.  The  final  device  ser¬ 
vice  routine  and  task  software  has  not  been  completed. 
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3.4  Player  Initializer  Laser  Designator  and  Target  Board. 

The  laser  designator  is  a  modified  M-16  laser  which  is  hard¬ 
wired  to  the  Player  Initializer.  During  player  initialization,  the 
operator  enters  the  marksmanship  level  of  the  player,  and  whether  or  not 
he  is  wearing  body  armor.  The  system  assigns  him  a  unique  "ID  NUMBER"  or 
identification  number.  At  a  later  time  when  the  real  player  has  put  on 
his  Player  Pack  and  is  ready  for  initialization,  the  operator  enters  the 
Initialize  Player  (IP)  command,  enters  the  ID,  and  "shoots"  the  player 
with  a  special  code  containing  the  ID  assigned  to  the  player.  The 
player's  Player  Pack  accepts  the  ID  from  the  laser  message  and  loads  it 
as  his  ID.  The  Player  Pack  and  .the  entire  system  can  now  be  checked  out 
using  the  Display  Player  Status  (DPS)  command  which  displays  on  the  CRT 
the  player's  position  (x,  y,  z);  alive,  dead  or  wounded,  total  rounds 
fired,  and  the  status  of  all  of  the  subsystem  elements. 

4  EXECUTIVE  COMPUTER  SYSTEM  OPERATING  SYSTEM. 

4.1  Background. 

The  TACTICS  instrumentation  must  be  extremely  flexible  to 
handle  new  and  unforeseen  applications  and  to  adapt  to  those  applications 
quickly  and  inexpensively.  The  use  of  a  modular  structure  and  a  common 
bus  protocol  in  the  hardware  reflects  this  need.  Accomodating  this 
requirement  in  the  software  structure  is  not  nearly  so  straightforward, 
but  it  has  been  done.  The  software  is  also  modularly  structured  and  all 
modules  obey  the  same  set  of  common  protocols,  but  the  structure  itself 
does  not  solve  muny  of  the  strictly  software-related  problems  that  arise 
in  every  event-driven  environment.  A  typical  example  of  this  problem  is 
the  resource  allocation  conflict  caused  by  multiple,  nearly  simultaneous 
weapon  engagements.  Here,  the  player  is  engaged  and  the  RTCA  process  is 
Invoked  and  the  second  engagement  occurs  before  the  previous  RTCA  has 
completed.  What  should  be  with  the  second  set  of  engagement  data? 
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Should  it:  (1)  be  Ignored,  (2)  preempt  the  current  RTCA,  (3)  be  queued 
and  subsequently  processed,  or  (4)  be  concurrently  processed? 

A  thorough  examination  of  the  Impacts  on  software  of  an  event- 
driven,  rapidly  changeable,  reliable  software  structure  led  to  the  choice 
of  the  operating  system  concept  widely  used  in  commercial  minicomputers. 
Even  within  this  conceptual  structure  there  are  many  alternative 
approaches  that  have  been  used  successfully.  The  one  chosen,  however,  is 
the  most  compatible  with  all  of  the  conditions  and  constraints  simul¬ 
taneously:  a  multi-tasking,  multi-user,  event-driven,  real-time  operat¬ 
ing  system.  This  provides  the  software  core  that  controls  system  timing, 
resource  allocation,  process  creation  and  deletion,  and  all  of  the  actual 
device  control  for  physical  input/output  of  data.  Acquisition  and  pro¬ 
cessing  of  the  data  are  handled  by  a  collection  of  separate  programs  or 
"tasks",  which  execute  under  control  of  the  operating  system  and  make 
"supervisor  calls"  to  OS  routines  to  perform  commonly  required  functions. 
This  approach  lumps  all  coordination,  device  control,  and  resource 
allocation  into  a  single  core  module  which  is  stable,  and  all  data 
processing  into  separate  submodules  which  are  easily  modified  without 
impacting  the  operational  control  functions.  This  division  of  software 
offers  a  highly  reliable,  very  flexible  structure  in  which  changes  can  be 
made  very  rapidly  with  low  risk. 

4.2  ECS  Functional  Description. 

A  complete  description  of  the  internal  workings  of  ECS  is  well 
beyond  the  scope  of  this  document  and  is  one  of  the  tasks  in  the  follow- 
on.  What  follows  is  a  brief  summary. 

ECS  is  a  collection  of  interactive  modules  which  together 
provide  both  a  stable  computer  environment  and  common  data  management 
services  for  the  programs  which  actually  process  the  real-time  player- 
related  data.  The  major  modules  are  the  task  scheduler,  the  input/output 
(I/O)  supervisor,  the  task  manager,  and  the  memory  manager. 


The  memory  manager  maintains  the  undedicated  memory.  That  Is, 
It  Is  a  "bookkeeper"  which  keeps  track  of  how  much  and  where  there  is 
memory  in  the  computer  that  Is  not  currently  in  use.  Tasks  or  ECS  may 
request  for  reuse  by  another  process.  The  net  effect  of  this  module  on 
the  overall  performance  is  that  the  computer  “appears"  to  have  much  more 
memory  than  it  actually  has. 

The  task  manager  is  responsible  for  process  creation  and  dele¬ 
tion  and  for  maintaining  the  priority  queues  for  the  task  scheduler. 
When  an  event  occurs,  the  task  manager  is  invoked  to  "create"  the  process 
that  handles  the  data  for  the  event.  This  involves  loading  a  program 
from  EPROM  into  the  location  memory  allocated  by  the  memory  manager, 
relocating  it,  and  placing  the  task  on  the  proper  priority  queue  for  the 
scheduler.  When  the  task  finishes  processing  the  data,  it  invokes  that 
task  manager  to  delete  the  process.  This  includes  removing  it  from  the 
scheduler  queue  and  releasing  the  memory  it  occupies  for  reuse  by  other 
processes.  The  task  manager  provides  the  solution  to  the  resource  allo¬ 
cation  conflict  mentioned  earlier:  for  each  separate  engagement,  a  new 
process  (RTCA)  is  created  to  handle  the  data.  Thus  at  any  one  time  there 
may  be  several  RTCA  processes  in  progress. 

The  I/O  supervisor  is  invoked  by  a  task  whenever  data  must  be 
transferred  via  hardware.  All  I/O  requests  use  exactly  the  same  protocol 
so  that  a  task  may  access  data  from  any  device  without  being  concerned 
with  the  procedure  for  manipulating  the  device.  The  supervisor  passes 
the  request  to  the  specific  Device  Service  Routine  (DSR)  for  the  speci¬ 
fied  device  and  then  "suspends"  the  calling  task  until  the  I/O  process  is 
complete.  Once  a  task  is  suspended,  the  central  processing  unit  (CPU)  is 
available  to  other  processes  until  the  I/O  process  is  complete.  This 
makes  maximum  use  of  the  CPU  to  perform  other  functions. 

The  task  scheduler  is  invoked  every  SO  milliseconds  by  the 
real-time  clock  or  whenever  a  task  is  suspended.  Its  basic  function  is 
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to  search  the  priority  queues,  in  order,  to  find  a  task  awaiting  the  CPU. 
When  it  finds  a  task,  the  scheduler  resets  its  clock  and  passes  control 
of  the  CPU  to  the  tasks.  This  assures  that  all  active  tasks  get  CPU  time 
on  a  regular  basis  (no  "‘.ookout")  and  that  whenever  a  task  is  suspended 
for  I/O,  the  time  for  I/O  is  used  effectively  by  executing  other  tasks. 

4.3  ECS  Status. 

ECS  was  first  loaded  for  execution  in  February  and  was  debugged 
and  fully  tested  in  April.  Since  April  it  has  been  used  continuously 
with  no  evident  problems.  It  has  been  used  successfully  in  both  the 
player  configuration  and  in  the  Player  Initializer. 

4.4  Task  Software. 

All  tasks,  whether  in  the  player  or  in  the  Player  Initializer, 
execute  under  control  of,  and  in  conjunction  with,  ECS.  Some  of  the 
tasks  are  common  to  both,  but  most  are  not.  In  either  case  the  basic 
operational  structure  is  similar.  In  the  Player  Initializer,  a  keyboard 
monitor  accepts  commands  from  the  CRT  keyboard  and  processes  them. 
Figure  8  lists  the  commands  available.  In  the  player  a  similar  module, 
the  RF  command  interpreter,  accepts  commands  from  the  Player  Initializer 
'ia  the  radio  and  processes  them.  In  both  cases,  commands  are  processed 
by  invoking  the  task  manager  to  execute  a  separate  task  whose  sole  pur¬ 
pose  is  to  process  the  specified  command.  This  minimizes  the  amount  of 
memory  allocated  to  command  processing. 

4.5  Player  Tasks. 

The  set  of  tasks  that  constitute  a  "player"  are  (1)  the  RF 
command  interpreter,  (2)  the  posit ion- location  algorithm,  (3)  RTCA,  (4) 
the  Player  Status  Monitor  (PMS),  and  (5)  any  other  tasks  required  for  the 
particular  player  application.  Of  these,  only  the  RF  command  interpreter 
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A.  Display  Commands 

DE  Display  Events 
DBS  Display  Battle  Statistics 
DPO  Display  Player  Data 
DPS  Display  Player  Status 
HPA  Halt  Player  Action  Plot 

B.  List  Commands 

LC  Li st  Commands 

LT  List  Teams 

LPI  List  Player  Information 

LPL  List  Position  Location  Groups 

LDR  List  Direct  Ranging  Groups 

LTC  List  Transponder  Coordinates 

C.  Show  Commands 

SPS  Show  Player  Status 
SDT  Show  Time  and  Date 

D.  Test  Commands 
Start  Start  Test 
Stop  Stop  Test 

E.  Pre-Test  Initialization  Commands 
BPI  Build  Player  Information 
DELP  Delete  Player  Information 
BT  Build  Teams 

IP  Initialize  Player 


Figure  8.  Executive  control  system  commands 
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BPL  Build  Position  Location  Task  Set 

BTS  Build  Test  Task  Set 

BDR  Build  Direct  Range  Task  Set 

STS  Set  Transponder  Coordinates 

SPL  Set  Position  Location  Groups 

SDR  Set  Direct  Ranging  Groups 

CTPL  Calibrate  Transponder  Position  Location 

CPL  Change  Position  Location  Groups 

CDR  Change  Direct  Ranging  Groups 

XPL  Start  Position  Location  Cycles 

XDR  Start  Direct  Ranging  Cycles 

HPL  Halt  Position  Location  Cycles 

HDR  Halt  Direct  Ranging  Cycles 

RA  Reload  Ammunition 

KP  Kill  Player 

RP  Revive  Player 

BIT  Do  Built-in-Test 

F.  Post-Test  Data  Recovery 
UP  Unload  Player  Data 

G.  Miscellaneous  Master  Station  Commands 

IDT  Initialize  Time  and  Date 
IPSM  Initialize  Player  Status 
RSET  Reset  Player  Status  Monitor 
LM  List  Memory 
MM  Modify  Memory 
XT  Execute  Task 
KT  Kill  Task 
CRU  Ready  Write  CRU 
Q  Quit 

Figure  8.  Executive  control  system  commands  (Continued) 
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and  the  player  status  monitor  are  fully  implemented.  The  PSM  is  imple¬ 
mented  as  an  extended  operation  (XOP)  within  the  structure  of  ECS.  This 
makes  it  globally  accessible  and  memory  resident.  The  operational  phi¬ 
losophy  of  all  player  software  is  asynchronous  "on  demand".  That  is,  as 
events  occur,  the  event  data  are  queued  in  an  event  buffer  accessible  by 
the  command  interpreter.  The  queing  is  done  by  the  event  processing  task 
via  supervisor  calls  to  ECS.  The  PMS  is  also  invoked  by  the  task  to 
reflect  the  occurrence  of  the  particular  event.  When  the  player  receives 
a  "send  status"  command,  the  command  interpreter  reads  the  status  from 
the  PSM  and  transmits  it  without  examining  it  in  any  way  and  waits  for 
the  next  command.  If  the  status  message  indicates  that  an  event  message 
is  present,  the  Player  Initializer  will  issue  a  "send  event"  command.  On 
receipt  of  a  "send  event"  command,  the  command  interpreter  will  transmit 
whatever  data  are  in  the  event  buffer  without  examining  it.  In  this 
manner,  events  are  sent  "on  demand"  in  chronological  order.  In  the  case 
that  no  "send  event"  commands  are  received  by  the  player  for  whatever 
reason,  all  of  the  events  are  still  resident  in  the  event  buffer  at  the 
end  of  the  test  and  can  be  retrieved  at  that  time.  The  event  buffer  can 
grow  as  needed  to  hold  event  data  limited  only  by  the  total  amount  of 
memory  available  in  the  Player  Pack.  This  "demand  mode"  of  operation 
assures  that  the  maximum  amount  of  both  CPU  time  and  system  memory  is 
always  available  for  use  in  processing  real-time  test-related  data. 

4.6  Player  Initializer  Tasks. 

The  Player  Initializer  contains  many  more  tasks  than  were 
originally  anticipated  due  to  cancellation  of  funding  for  the  master 
station.  The  operational  philosophy  is  similar  to  that  of  the  player. 
Each  function  is  performed  by  a  separate,  small,  simple  task  and  the 
coordination  of  these  tasks  produces  the  overall  results.  Test  operation 
can  be  visualized  as  a  set  of  foreground  tasks  (status  display,  event 
lists,  etc.)  and  background  tasks  (PL  coordination,  event  data  transfers, 
etc.)  which  occur  at  regular  intervals  with  no  human  intervention. 
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DEVELOPMENT  OF  A  SIMPLIFIED  TRANSPONDER  POSITION  LOCATION 
ALGORITHM. 


Traditionally,  this  problem  has  been  solved  using  large  com¬ 
puters  and  Kalman  filters.  Various  attempts  at  using  classical  least 
squares  techniques  met  with  failure  due  to  algorithmic  instabilities 
induced  by  imperfect  range  measurements.  For  the  TACTICS  distributed 
instrumentation,  the  calculations  are  performed  in  the  microcomputer  of 
the  Player  Pack.  This  limitation  precludes  use  of  the  Kalman  filter 
approach  on  the  basis  of  both  computation  time  in  the  microcomputer  and 
memory  requirements  of  the  Kalman  algorithm.  The  least  squares  approach 
was  resurrected  and  modified  to  handle  the  nonlinear  instabilities  using 
a  relatively  obscure  formalism  originally  put  forward  by  Marquardt  in 
1966.  This  approach  was  formally  adapted  to  the  position-location  prob¬ 
lem  fnd  coded  in  FORTRAN  for  experimentation.  The  formal  algorithm  works 
quit:  well,  but  is  nearly  as  large  and  slow  as  the  Kalman  filter  approach. 
Additional  work,  both  analytical  and  empirical,  showed  that  the  bulk  of 
the  formal  algorithm  could  be  deleted  for  the  specific  application  to  the 
transponder  position-location  problem.  The  basic  difficulty  with  the 
classical  least  squares  technique  is  that  the  transfer  matrix  is  not 
positive  definite  as  a  result  of  the  recursion  function  being  nonlinear. 

Imperfect  range  data  result  in  an  error  function  which  is  cubic 
(or  worse)  rather  than  quadratic.  The  combination  of  these  effects 
forces  classical  techniques  to  converge  to  spurious  solutions  yielding 
very  unstable  sequential  results  and  large  position-dependent  errors. 
The  technique  adapted  reduces  the  matrix  to  simple  correlation  coeffi¬ 
cients  among  the  derivatives  of  the  recursion  function  which  forces  it  to 
be  symmetric.  An  additional  term,  a  variable  in  the  formalism  but  fixed 
in  practice,  is  applied  to  make  the  matrix  diagonal  dominant  which  assures 
that  it  is  always  positive  definite  regardless  of  the  quality  of  the 
input  data.  This  in  turn  guarantees  convergence  to  a  stable  solution. 
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The  algorithm  was  coded  Into  FORTRAN  and  debugged,  some  slight 
modifications  performed  to  aid  the  weighting,  and  the  algorithm  was 
tested.  Figure  9  shows  the  results.  These  are  rather  encouraging  -  the 
algorithm  is  quite  precise,  fast,  and  robust.  Several  tests  were  per¬ 
formed  to  gauge  the  impact  of  errors  in  the  data  on  the  algorithm.  The 
algorithm  is  very  hard  to  foil,  even  with  data  calculated  to  simulate 
worst-case  errors.  As  the  program  closed,  the  algorithm  was  being  trans¬ 
lated  from  FORTRAN  to  assembler. 

6  DEVELOPMENT  OF  A  SIMPLIFIED  REAL-TIME  CASUALTY  ASSESSMENT 

ALGORITHM. 

The  primitive  real-time  casuality  assessment  algorithm  assumes 
that  the  probability  of  a  wound  or  kill  relates  to  the  following: 

(a)  Range  between  firer  and  fired  upon. 

(b)  The  marksmanship  level  of  the  firer. 

(c)  The  weapon  used. 

(d)  The  posture  of  the  firer. 

The  way  in  which  this  information  relates  to  the  probability  of 
a  wound  or  kill  is  that  inverse  range  is  a  good  estimator  of  the  prob¬ 
ability  of  a  wound  or  kill  as  the  ratio  of  the  beam  size  to  the  bullet 
path  is  large.  One  must  work  with  normalized  ranges  to  translate 
directly  into  probabilities.  The  markmanship  level  is  used  to  slightly 
shift  the  statistics  to  improve  a  shooter's  score  as  his  marksmanship 
level  improves.  The  weapon  used  plays  into  the  calculation  because  some 
weapons  are  more  accurate  at  longer  distances  than  others. 

The  two  weapons  that  are  of  interest  here  are  the  M-16  and  the 
357  handgun.  Posture  too  enters  the  calculation.  When,  for  example,  a 
person  is  prone  he  shoots  more  accurately;  if  the  target  is  prone  it  is 
more  difficult  to  engage. 
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Figure  9.  Transponder  position  location  algorithm  output 


The  current  algorithm  solves  the  following  equation: 


P(w)  ■  R  +  M  +  Pos  +  Weapon 
Where 

P(w)  Is  the  probability  of  a  wound 
R  Is  the  range 
M  Is  the  marksmanship  level 
Pos  is  the  posture 
Weapon  is  the  weapon  fired 

The  result  is  not  a  true  probability,  but  an  address  into  a 
table  which  contains  the  probability  of  a  kill.  Wounding  is  not  handled 
at  this  time. 


DISTRIBUTION  LIST 


DEPARTMENT  OF  DEFENSE 

U.S.  Docunients  Officer 
AESOUTH 

ATTN:  U.S.  Documents  Officer 

Armed  Forces  Staff  College 

ATTN:  Reference  &  Technical  Svcs  Br 

Assistant  Secretary  of  Defense 
International  Security  Affairs 
AHN:  NATO  Nuc  Policy  Div 
ATTN:  P  &  P  Nuclear  Policy 
AHN:  Policy  Plans  &  NSC  Affairs 

Assistant  Secretary  of  Defense 
Coom,  Cmd,  Cent  &  Intell 

ATTN:  Intelligence  Sys 

ATTN:  Surveillance  &  Warning  Sys 

ATTN:  Combat  Support 

Assistant  Secretary  of  Defense 
Program  Analysis  A  Evaluation 
ATTN:  Strategic  Programs 
ATTN:  Regional  Programs 
ATTN:  General  Purpose  Programs 

Assistant  Secretary  of  Defense 
International  Security  Policy 

ATTN:  European  A  NATO  Affairs 

Assistant  to  the  Secretary  of  Defense 
Atomic  Energy 

ATTN:  Executive  Assistant 

Command  A  Control  Technical  Center 
Department  of  Defense 
ATTN:  C331/NCPS 

Commander-In-Chief.  Pacific 
ATTN:  J-6 
ATTN:  0-3 
ATTN:  0-2 
ATTN:  0-54 

Defense  Advanced  Rsch  ProJ  Agency 
AHN:  TTO 

Defense  Conmunlcatlons  Agency 
ATTN:  Director 

Defense  Comnunlcatlons  Engineer  Center 
AHN:  R-123 

Defense  Intelligence  Agency 
AHN:  RTS-2C 
AHN:  DT-1 

Defense  Nuclear  Agency 
ATTN:  STSS 
4  cy  AHN:  TITL 


DEPARTMENT  OF  DEFENSE  (Continued! 

Defense  Technical  Information  Center 
12  cy  ATTN:  DD 

Field  Coamand 
Defense  Nuclear  Agency 
Livermore  Branch 
ATTN:  FCPRL 

Field  Coamand 
Defense  Nuclear  Agency 
Los  Alamos  Branch 

AHN:  MS-635.  FCPRA 

Intelligence  Center,  Pacific 
Department  of  Defense 
ATTN:  1-3 

Interservice  Nuclear  Weapons  School 
ATTN:  TTV  3416th  nSQ 

Oolnt  Chiefs  of  Staff 
AHN:  SAGA 
ATTN:  0-3 

ATTN:  0-5  Nuclear  Division/Strategy  Div 

Oolnt  Strat  Tgt  Planning  Staff 
AHN:  OP 
AHN:  OL 


National  Defense  University 


ATTN; 

NWCLB-CR 

Director 

Net  Assessment 

AHN: 

Dir  A.  Marshall 

U.S.  European  Ccmmand 

ATTN: 

0-5 

ATTN: 

0-4/7-LW 

ATTN: 

0-3 

ATTN: 

0-2 

ATTN: 

0-6 

AHN: 

0-2- ITD 

AHN: 

0-5NPG 

U.S.  National  Military  Representative 
SHAPE 

ATTN:  U.S.  Doc  Ofc  for  Ops,  Nuc  Plans 

Under  Secretary  of  Defense  for  Rsch  &  Engrg 

ATTN:  Strat  t  Theater  Nuc  Forces,  B.  Stephan 
ATTN:  Strategic  &  Space  Sys  (OS) 

DEPARTMENT  OF  THE  ARMY 

Deputy  Under  Secretary  of  the  Array 

ATTN:  Mr.  Lester,  Operations  Research 


DEPARTMENT  OF  THE  ARMY  (Continued) 

Deputy  Chief  of  Staff  for  Ops  &  Plans 
Department  of  the  Army 
ATTN:  DAMO-SSW 
ATTN:  DAMO-RQS 
ATTN:  DAMO-NCC,  V.  Fenwick 
ATTN:  DAMO-ZD.  C.  Williams 
ATTN:  DAMO-SSN.  LTC  Cooper 

Deputy  Chief  of  Staff  for  Rsch  Dev  &  Acq 
Department  of  the  Army 

ATTN:  DAHA-CSS-N.  W.  Murray 

ATTN:  Advisor  for  RDA  Analysis,  M.  Gale 

ATTN:  DAMA-CSM-N 


DEPARTMENT  OF  THE  ARMY  (Continued) 

U.S.  Army  Materiel  Dev  &  Readiness  Cmd 
ATTN:  DRCDE-DM 

U.S.  Army  Materiel  Sys  Analysis  Actvy 
ATTN:  DRXSY-S 
ATTN:  DRXSY-DS 

U.S.  Army  Missile  &  Munitions  Ctr  S  School 
ATTN:  ATSK-DS-AS-S 

U.S.  Army  Nuclear  &  Chemical  Agency 
ATTN:  Library  for  MONA-SAL 
ATTN:  Library  for  MONA-ZB 


Electronics  Tech  &  Devices  Lab 
U.S.  Army  Electronics  R  &  0  Conmand 
ATTN:  DELEW.  R.  Freiberg 

Harry  Diamond  Laboratories 
Department  of  the  Army 
ATTN:  DELHD-NW-RA 
ATTN:  DELHD-TD,  W.  Carter 
ATTN:  DELHD-NW-P,  F.  Balicki 

Measurement  ECM  &  Support  Technical  Area 
Department  of  the  Arruy 

ATTN:  DRSEL-WL-M-M 


U.S.  Army  TRADOC  Sys  Analysis  Actvy 
ATTN:  ATAA-TDC,  J.  Hesse 

U.S.  Army  Training  and  Doctrine  Comd 
ATTN:  ATOO-NCO 

U.S.  Army  War  College 

ATTN:  AWCI,  R.  Rogan 

USAMICOM 

Department  of  the  Army 
AHN:  DRCPM-PE 

ATTN:  DRSMI-YDR,  Foreign  Intelligence  Office 


Office  of  the  Chief  of  Staff 
Department  of  the  Army 
ATTN:  DACS-DMO 

U.S.  Army  Air  Defense  School 
ATTN:  ATSA-CD-SC 

U.S.  Army  Armament  Rsch  Dev  &  Cmd 
ATTN:  DRDAR-LCN-E 

U.S.  Army  Ballistic  Research  Labs 
ATTN:  DRDAR-BLV 


V  Corps 

Department  of  the  Army 

AHN:  AETVFAS-F,  P.  Reavill 

VII  Corps 

Department  of  the  Army 
ATTN:  AETSFA-FSE 
ATTN:  AETSGB-I 
ATTN:  AETSGC-0 
AHN:  AETSGB-0 

DEPARTMENT  DF  THE  NAVY 


U.S.  Army  Chemical  School 
ATTN:  ATZN-CM-CS 

U.S.  Army  Comb  Arms  Combat  Dev  Acty 
ATTN:  ATZLCA-DLT 

U.S.  Army  Concepts  Analysis  Agency 
ATTN:  CSCA-RQN 

U.S.  Amiy  Elct  Warfare  Lab  (ECOM) 
ATTN:  DELEW-M-FM,  S.  Hegeatl, 


David  Taylor  Naval  Ship  R  &  D  Ctr 
AHN:  Code  174/Code  186 

Naval  Material  Command 
AHN:  MAT-OON 

Naval  Ocean  Systems  Center 

ATTN:  Research  Library 

Naval  Postgraduate  School 

ATTN:  Code  1424.  Library 


Commander-in-chief 
U.S.  Army  Europe  and  Seventh  Army 
ATTN:  OCSOPS-AEAGC-O-N 
ATTN:  AEA66 
ATTN:  AEAGO-MM 

U.S.  Army  FA  Hsi  Sys  Eval  Gp 
ATTN:  ATZR-MG 


Naval  Surface  Weapons  Center 

ATTN:  Code  F32,  W.  Emberson 
AHN:  Code  F31 
ATTN;  Code  X211 

Naval  War  College 

ATTN:  Center  for  War  Gaming 
ATTN:  12 


U.S.  Army  Forces  Comnand 
AHN:  AFOP-COE 


Naval  Weapons  Center 
ATTN:  Code  32607 


32 


P 


DEPARTMENT  OF  THE  NAVY  (Continued) 


DEPARTMENT  OF  THE  AIR  FORCE  (Continued) 


Naval  Weapons  Evaluation  Facility 
AHN:  Code  70 

Nuclear  Weapons  Tng  Group,  Atlantic 
Department  of  the  Navy 

ATTN:  Technical  Library 

Office  of  Naval  Research 
ATTN:  Code  713 

Office  of  the  Chief  of  Naval  Operations 
ATTN:  NOP  654 

Plans  &  Policies  Department 
Headquarters  Marine  Corps  (Code  PL) 
Department  of  the  Navy 

ATTN:  Joint  Strategic  Branch 

Commander-In-Chief 
U.S.  Atlantic  Fleet 
Department  of  the  Navy 
ATTN:  Code  J-54 
ATTN:  Code  J-34 

Commander-In-Chief 
U.S.  Naval  Forces,  Europe 
ATTN:  N54 

DEPARTMENT  OF  THE  AIR  FORCE 
Headquarters 

Aerospace  Defense  Comnand 
Department  of  the  Air  Force 
ATTN:  ADCOM/INA 

A1r  Force  Armament  Laboratory 
ATTN:  AFATL/DLY 

A1r  Force  Weapons  Laboratory 
Air  Force  Systems  Command 
AHN:  AFWL,  SA 
AHN:  NSSB 
ATTN:  SUL 
ATTN:  NTN 

Air  University  Library 
Department  of  the  Air  Force 
AHN:  AUL-LSE 


Tactical  Air  Command 

Department  of  the  Air  Force 
ATTN:  TAC/XPJ 

Tactical  Air  Command 

Department  of  the  Air  Force 
ATTN:  TAC/XPS 

Comnander-ln-Chlef 

U.S.  Air  Forces  In  Europe 
AHN:  USAFE/INAT 

Conmander-ln-Chlef 

U.S.  Air  Forces  In  Europe 
ATTN:  USAFE/XPX 

Comnander- 1 n-Chl ef 

U.S.  Air  Forces  In  Europe 
ATTN:  USAFE/XPXX 

OTHER  60VERN1€NT  AGENCY 

Central  Intelligence  Agency 
ATTN:  OSWR/NED 

DEPARTMENT  OF  ENERGY 

Department  of  Energy 

AHN:  OMA,  D.  Hoover 

DEPARTARTHENT  OF  ENERGY  CONTRACTOR 

Lawrence  Livermore  National  Lab 
ATTN:  L-9,  D.  Blumenthal 
AHN:  L-21,  M.  Gustavson 
AHN:  L-9,  R.  Barker 

Los  Alamos  National  Laboratory 
ATTN:  G.  Best 

Sandia  National  Lab 

ATTN:  5612,  0.  Keizur 
AHN:  5613,  R.  Stratton 

DEPARTMENT  OF  DEFENSE  CONTRACTORS 

Advanced  Research  S  Applications  Corp 
ATTN:  R.  Arml stead 


Assistant  Chief  of  Staff 
Studies  &  Analyses 
Department  of  the  Air  Force 
ATTN:  AF/SAMI 

Deputy  Chief  of  Staff 
Operations  Plans  and  Readiness 
Department  of  the  Air  Force 

ATTN:  AFXOXF,  R.  Linhard 
AHN:  AFXOXFM 

Deputy  Chief  of  Staff 
Research.  Development,  &  Acq 
Department  of  the  Air  Force 
ATTN:  AFRDQI 


AVCO  Research  &  Systems  Group 
ATTN:  G.  Grant 
ATTN:  J.  Gilmore 


Battelle  Memorial  Institute 
ATTN:  0.  Hainnan 


BDM  Corp 

ATTN:  J.  Braddock 
BDM  Corp 

ATTN:  T.  NcWIIUbik 
4  qy  ATTN:  T.  Andrews 
4  cy  ATTN:  M.  Ondrik 
4  cy  ATTN:  G.  Pax 
4  cy  ATTN:  C.  Mold 


33 


■PARTMENT  OF  DEFENSE  COHTRACTOftS  (Continued) 

xnputer  Sciences  Corp 
AHN:  F.  Eisenbarth 

ineral  Research  Corp 
ATTN:  P.  Lowry 
ATTN:  H.  Schroeder 

idson  Institute.  Inc 
AHN:  H.  Kahn 

lYCOR 

AHN:  R.  Sullivan 
ATTN:  E.  Almquist 

lYCOR 

AHN:  S.  Brucker 

iinan  Sciences  Corp 
ATTN:  F.  Shelton 

iman  Ten^o 

ATTN:  DAS I AC 

ckheed-CallfornIa  Co 
ATTN:  G.  Busch 

sslon  Research  Corp 
ATTN:  Tech  Library 

clfIc-Slerra  Research  Corp 
ATTN:  H.  Brode 

&  D  Associates 
ATTN:  A.  Lynn 
ATTN:  S.  Cohen 
ATTN:  P.  Haas 


DEPARTMENT  OF  DEFENSE  CONTRACTORS  (Continued) 

Rand  Corp 

AHN;  Library 
AHN:  M.  Jones 

Santa  Fe  Corp 

ATTN:  D.  Paolucci 

Science  Applications.  Inc 
ATTN:  J.  Martin 
ATTN:  M.  Drake 

Science  Applications.  Inc 
AHN:  M.  Layson 

SRI  International 

ATTN:  P.  Dolan 
ATTN:  D.  Elliott 

SRI  International 

ATTN:  R.  Foster 

Systems.  Science  &  Software.  Inc 
AnN:  K.  Pyatt 

Tetra  Tech.  Inc 

ATTN:  F.  Bothwell 

TRW  Defense  &  Space  Sys  Group 
ATTN:  P.  Dal 

TRW  Electronics  &  Defense  Sector 
AHN:  N.  Lipner 

Vector  Research.  Inc 
ATTN:  S.  Bonder 


34 


